In light of recent tightening of the credit markets and general drop-off in demand, telecommunications carriers are increasingly pressured to maximize return on their existing infrastructure and/or make wise choices when purchasing and deploying new telecommunications gear. Due in part to their cost and potential performance bottlenecks, especially when stretched beyond nominal loads, call processing systems within the carrier's network have drawn heightened scrutiny.
Traditional time-domain switched, voice-oriented communications typically included a single call processing unit tightly coupled to and servicing a given switch fabric or a dedicated portion thereof. Smaller, enterprise class telecom solutions such as a digital key system or private branch exchange included one call processing unit, whereas carrier grade central office solutions involved a dedicated call processing unit servicing a dedicated portion of the central office switching fabric. TDM switching techniques assured an actual or virtual connection be established and maintained for the duration of a call, at the expense of resource efficiency and dynamism.
With the advent of packet voice and softswitch solutions, the call processing system has been decoupled from the actual or virtual switching fabric, and a number of multi call processor designs have been developed, since each call processing unit is now capable of handling almost any call originating from or terminating to the larger system.
A representative multiple processor call processing system 2500 is shown in FIG. 25. In this system, plural individual call processing units or PMCis, including PMC1 2515 and PMC2 2520 and PMCK 2525; collectively handle a number of call processing activities and call events. The managing call processing unit, or PMC-M 2510, performs other call processing activities and events. Typically, in known multiple call processing system architectures, the PMCis 2515, 2520 and 2525 handle the bulk of the “individual call” oriented activities and tasks based on the subset of system calls they are assigned to handle, whereas the PMC-M 2510 is primarily responsible for coordinating operation of the PMCis as needed for e.g. system-wide call admission control and load balancing. As such, communication of coordination information (not shown) such as control, status, query and reporting messages occurs between these PCMis 2515,2520, 2525 and the PMC-M 2510 on a periodic and/or event-driven basis.
A well-known goal that multiple processor call processing systems (such as the system 2500 shown in FIG. 25) attempt to achieve with respect to call admission control (CAC) and load balancing is to maintain the QoS commitment for the existing calls (failing to introduce delays or packet loss in packet voice environments) while maximizing call capacity, and ultimately maximize efficient use of the call processing system. In particular, the goal is to provide an optimally efficient call handling situation in which all individual call processing units in a multiple processor call processing system are evenly and homogeneously (with respect to call type) loaded. Thus, ideally, call admission control and new call blocking will thus only occur where all these call processing units are already fully or nominally loaded.
To illustrate, refer to a simplified capacity diagram of a 6 PMCi call processing system 105 shown in FIGS. 1A-1C, generally consistent with the system 2500 shown in FIG. 25. As shown in each of FIGS. 1A-1C, each box within each PMC1 . . . PMC6 represents a call, with a shaded box 110 representing a voice call, a diagonally hatched box 112 representing a streaming call, and a transparent double-sized box 114 representing an interactive call. Each container 107 represents the capacity of a given PMCi. In FIG. 1A, the PMC1 . . . PMC6 of the multiple processor call processing system 105 are evenly and homogeneously loaded; in FIG. 1B, the load is even but not homogeneous; and in FIG. 1C the load is neither homogeneous nor even.
The risk presented in FIG. 1B is that if there is congestion in a given PMCi, most calls within such PMCi might be of the same nature thus making any call processing remedy more difficult. The risk posed in FIG. 1C is that while there is unused capacity on some PMCis (e.g. PMC2, PMC4, PMC6), other PMCis (e.g. PMC1, PMC3, PMC5) are very close to their nominal load and may not be able to provide sufficient service level guarantees or quality of service to the calls they are handling. As a result, the goal should be to maintain even and homogenous loads, as in FIG. 1A. It should also be noted that even this situation, the call processing system 105 may reach a loading condition where all the PMC1 . . . PMC6 are nominally loaded, and that the system cannot admit further new calls, but this situation happens less often, if the load is even.
In order to load balance a multiple processor call processing system, it is important to be able to estimate the resource utilization (in terms of e.g. bandwidth or processor loading) on each call processing unit at any given time. Once the per PMCi estimated loading is determined, one can prospectively load balance by admitting new calls based on which PMCi has free resources to handle the call. A simple brute force approach is to assume that each call is taking up its peak resource requirement, and that the estimated load is based on this peak resource requirement multiplied by the number of calls being handled. This obviously results in inefficient resource under-utilization, and cuts against some of the perceived variable bandwidth advantages afforded by packet voice transmission.
Another known technique for estimating resource utilization is based on a relationship between peak and average resource requirements for a given call type, e.g.:
                                                                        estimated                ⁢                                                                  ⁢                resource                ⁢                                                                  ⁢                utilization                                                                                        for                ⁢                                                                  ⁢                a                ⁢                                                                  ⁢                given                ⁢                                                                  ⁢                call                ⁢                                                                  ⁢                type                                                    =                              2            *            peak            *            average                                peak            +            average                                              (        1        )            Once the estimated resource utilitization for the different call types being or expected to be handled within the call processing system is known, each PMCi's loading can be estimated by determining how many of each type of calls are being serviced and multiplying each by this estimated resource utilization. Resources can be reserved within each of the PMCi consistent with the estimated resource utilization and additional capacity can be determined based on remaining unreserved resources.
FIG. 2 illustrates a plot of the estimated resource utilization curve 202 corresponding to the above equation (1) versus the average resource utilization. It is obvious that in this method, when the average is significantly smaller than the peak resource requirement, the estimated resource utilization approaches twice the average resource requirement (e.g. approaches line 204 having a slope of 2 in FIG. 2). Otherwise, the estimated resource utilization is always a 1 to 2 multiple of the average (e.g. always greater than, but approaching line 206 having a slope of 1). Ergo:average<<peakestimate=2×average  (2)average≅peakestimate=average=peak  (3)
Thus, using this estimated resource utilization technique results in a overly-conservative loading estimation for the PMCis (i.e. more resources are estimated being used than is actually the case) and can potentially result in a false determination that a given PMCi is at nominal loading or overloaded when it still in fact has capacity. The call processing system can refuse to provide additional calls to the so-overloaded PMCi which still in fact has capacity, and worse, may prematurely refuse to admit further calls to the system (assuming the remaining PMCis are estimated at nominal or greater loading). On the other hand, it is unlikely that any one PMCi will be overbooked or oversubscribed, thus this technique is perceived at least being QoS friendly.
Further, this estimated resource utilization technique does not take into account the number of calls of a given call type being handled by a given call processing unit. It is well-known that the greater the number of calls of a given type are being serviced by a given PMCi, the less is the chance that these behave all the same way or utilize the same amount of resources. For example, it is highly improbable that, in the case of packet voice with silence suppression, that all handled calls will be in the more resource demanding active, vs. silent state. To account for this, it is generally known that a provisionable reservation coefficient may be used to augment the above to permit the PMCis and the call processing system generally to accept more calls than the above-described conservative estimation technique calls for, and in the typical and aggressive cases, more than the PMCis and the call processing system as a whole can actually handle. This overbooking is justified, especially as the number of calls increases and the probabilistic nature of the calls with respect to actual resource utilization (the probabilistic nature of calls, as used herein, means that the resource utilization for each call varies by time and may have any of a finite or infinite number of values within known limits). However, in known systems, the reservation coefficient, although provisionable, is constant within different hours of a day or days of a week, unless a system operator manually alters or updates it.
Therefore, it would be advantageous in a multiple processor call processing system if critical resource utilization could be better predicted, and consequently more accurate call admission and load balancing decisions could be made without detracting from overall system performance.